Collection of Tools & Utilities/Collection of Tools and Utilities.iso/graphic/dbwrendr.zip/READ.ME

Text File | 1989-11-08 | 12KB | 286 lines

This IBM version of DBW_Render was ported from the AMIGA by me:

    John H. Lowery
    25 Mirror Place
    Oak Ridge, NJ 07438

Comments, questions and suggestions concerning the IBM version
should be directed there.  Please do, however, become a registered
user by send the suggested $18 shareware donation to:

    William T. Baldridge
    2650 Sherwood Lane
    Pueblo, CO 81005

who now administers DBW_Render for the author, David B. Wecker.

Please indicate that you are using the IBM-PC version 1.02, rather
than the AMIGA version.

If you develop any particularly neat pictures, please consider
uploading them ( in .DAT input file format, compressed with PKZIP or
ARC, as applicable ) to the bulletin board from which you obtained
this program.

I will make a point of posting the latest version of DBW_Render for
the IBM, and interesting input files, on the following BBS's:

    Chuck's Attempt (Sparta,  NJ)   [phone]
        Great Graphics  (Rahway,  NJ)   [phone]
    Just Programs   (Roselle, NJ)   [phone]
    The Invention Factory (NY, NY)  [phone]

.. and any other BBS that indicates an interest.

Please note that a version 2.0 of DBW_Render has become available
for the AMIGA, but has not been released as shareware, so no IBM
version is available (at this time).

The following comments are culled from those provided with the
AMIGA version of the software by Dave Wecker, but are equally
applicable to the IBM version:


-> What is the best way to "design" a picture?

In your .DAT file set the following parameters:

    a.    no transmission (everything opaque).
    b.    no "mirrors" (use low reflection/diffusion levels).
    c.    use only 1 light source.
    d.    make the light source infinitely far away ("l" not "L").
    e.    use a small numbers of objects.
    f.    no anti aliasing

This will allow you to prototype pictures VERY quickly (minutes not hours).
BTW: this is why JUGGLER only took its author 1 hour/frame to compute it used
items a,c,d and e,f (depending on def. of "small")

-> I seem to be using A LOT of stack when there are mirrored objects.. why?

If you have two (or more) highly reflective spheres (mirrored) and a bright
light sources, you probably STILL run out of stack because you have to bounce
the light back and forth between them for a LONG time (not infinite do to the
inverse square law)... you can patch the file RAY.C changing all occurrences
of:
     max_runs = 32767;

to a smaller number (somewhere between 30 and 300 for example). This will set a
much smaller maximum recursion value (and thus much smaller stack usage).

->    How do I go about positioning the eye/camera...

The easiest thing to do is to set the center of your image at (0,0,0). This is
what is done in the GLASS.DAT example. The eye is positioned at:

    (30,180,200) looking in the direction of (-50,-320,-350)

Ok.. so how does this give us (0,0,0)? Well, if you start at the eye and add
the direction vector you get (-20,-180,-150). It turns out that if you go 57%
of the way along the direction vector you get (0,0,0)!!! So you are looking
down and to the left through the origin and then 150 units further! By
adjusting this distance you can magnify or reduce the entire image.

At the tip of the vector you have 256 units in X visible and 170 units in Y
visible. This defines a viewing "cone" (which you can draw the lines out to).
But for example, in the plane of the screen (Z = 0), you have visible:

    x: -73 to +73        (57% of 256)
    y: -48 to +48        (57% of 170)

You can make this calculation for any desired depth.

->    Objects are getting FUZZ even when they have 0.0 "fuzziness"...

Remember that if you don't give the program enough time to run in, it will
"smear" objects by using the AI algorithms to guess at pixel values. Try to
give a small strip of the picture an infinite amount (999.0 hours) to run in
and you should see all pseudo-fuzz go away.

->    What EXACTLY do the AI heuristics do?

Most of the "guess-work" happens in the "ray.c" module. First of all, I keep a
cache of 9 lines (centered on the current line). This is used when the program
runs out of time on a line and needs to guess at a pixels value. Routine
"guess" calls "guess2" to scan out from the current pixel looking for computed
pixels which are averaged for a "best guess".

When you set a resolution (using "R" in the .dat file), an initial estimate is
made of how much time per scan line will be allowed. Pixels that are easy to
compute (max_runs = 10) are computed first. If we still have time (curtime <=
nxttime) or we haven't computed enough pixels (pixelcompute <= compmin
(described below)) we randomly pick pixels at full computational level
(max_runs = 32767) until either of the two previous conditions are met (or all
pixels on a line have been computed).

Here is where the heuristics come in. At the end of a scan line the following
estimates are made:

1.    The next scan line will be allowed to have time of:
        buftime      - normal time for a scanline
          + xtrtime/8 - "extra" time: either not used by previous scan
            lines (all pixels computed), or negative time (if
            previous scanlines used too much time).
2.    compthresh = (2/3) * pixelcompute
        This is the threshold at which max_runs switches over from
        10 to 32767 (recursion level). pixelcompute is the total
        number of pixels computed on prev scanline.
3.    compmin = (9/10) * pixelcompute
        This many pixels MUST be computed (even if we run out
        of time (this is how xtrtime can become negative)).

These estimates let us adaptively change how we decide the number of pixels
per line to compute. All pixels are chosen randomly to keep patterning out
of the picture.

->    The General License states that any derivative must fall under the
    terms of the license, does this mean that all pictiures created fall
    under the terms of the license?

No! The License only covers derivates of the CODE. Any pictures you create are
yours to do with as you please.

->    Can you explain "Global index of refraction"?

It's just what the documentation says... the index of the "air". For instance,
if you start increasing this value you can make the picture look like everyting
is under water (or embedded in glass).

->    Where should I set the anti aliasing parameters?

First read the documentation on the "A" setting, it's very detailed. Things to
remember:

1.    This parameter will help you get rid of the dreaded "jaggies"
    (jagged diagonal lines).

2.    If you set the COUNT to 4 each picture will take MINIMALLY
    4 times as long to compute. This is because you are now
    sending at LEAST 4 times as many rays through every pixel.

3.    The reason 2. says MINIMALLY is because of the THRESHOLD parameter.
    This measures the standard deviation in intensity of the COUNT rays
    sent through a pixel. If the SD is greater than the THRESHOLD than
    another COUNT rays are sent... and on and on until either the SD
    falls below the THRESHOLD or you've distributed 128 rays into a pixel
    (maximum).

4.    The results are then averaged to smooth out the "jaggies".

This is why there is a Z command to show you how much anti-aliasing actually
had to be done.

->    Just out of interest what do you do for a living and where did
    you go to school?

Head of AI tools for Digitial Equipment Corporation Database Systems Advanced
Development. Carnegie-Mellon Univ. (BSEE & MSIA).

->    I notice code for CYLINDER objects in RAY, why aren't they documented?

Cylinder was never completed (sorry).

->    What happens if two objects occupy the same space?

Which ever one is "sorted" first will be visable (pretty random).

->    Can you give me a picture of the coordinate system?

It's a little difficult to draw a picture of the coordinate system, but I'll
try using an example where the eye is at 30,180,200 and the direction vector is
-50,-320,-350. If you add these two points you get the focus point
(-20,-180,-150). At the focus point there are +- 128 units in X and +- 85 units
in Y. Here is the result (anything inside of the "viewing cone" is visable):